Business Analyst Community & Resources | Modern Analyst

What is XD?

Adrian M. — Sat, 12 Nov 2022 21:43:00 GMT

While XD is an acronym for a number of terms, in the world of the analyst XD stands for eXperience Design.

Experience Design (XD) is the practice (or discipline) of focusing on the people’s experience when using a given product or service. The XD practitioner approaches the design by considering the intended customer’s:

needs
feelings
emotions
mindset
expertise

Experience Design (XD) considers the impact of the prescribed interaction on the customer’s satisfaction in a variety of ways:

What are the customer’s expectations in terms of speed of the software?

Is the product usable by people with disabilities (hearing impaired, visually impaired, mobility impaired,d etc.)?

What could frustrate the customer as they use our product?

What assumptions could the customer have prior to using our service?

In order to achieve a positive user experience (UX), the XD team can use a number of different techniques and tools such as:

Persona Definition - identify the types of users the product or service is meant to serve.

User Research - detailed analysis and investigation of the habits, needs, wants, and peculiarities of the intended audience.

Focus Groups - talk and interact with the future users of the product.

Interface Definition - clearly and intentionally defining how the prospective customer will interface with your product or your service.

Prototyping - creating a scaled down version of the final product but more than just a conceptual design, allowing prospective customers to try your idea.

Beta Testing - enable a sample of the intended audience to try out your product and provide feedback - watching the customer use your product is also very valuable.

What else does XD stand for besides eXperience Design?

XD = Adobe XD

XD = eXtreme Design

XD = eXtreme Digital

XD = eX-Dividend

XD = Laughing face emoji

What is a Use Case Diagram?

Chris Adams — Sun, 11 Sep 2022 23:21:00 GMT

[Be the first to post an answer to this question!]

Compare a user story versus a use case. What are the essential elements of each? When would you use one versus the other?

Chris Adams — Sat, 08 Jan 2022 22:08:00 GMT

The essential elements of a user story are:

The user
Statement of what the user needs to accomplish
Why the need to accomplish this

The essential elements of a use case are:

The Actor carrying out the use case
Summary of the use case
Success criteria
Scenario detailing the steps the Actor follows to achieve the success criteria.

Why bother with identifying use cases? Why not jump straight to process flows?

Chris Adams — Thu, 07 Oct 2021 16:15:00 GMT

Whether documenting business processes or systems processes, use cases and process flows can both be valuable tools.

A use case description textually describes the main success scenarios of a process as well as the major alternate scenarios and exception scenarios. Process flows do the same thing, though in graphical form. A process flow documents the step by step activities of the main success scenario. Decision points (often shown as diamond shapes) show where the main scenario branches off into alternate scenarios.

How do you ensure that your use case model is effective?

Chris Adams — Fri, 12 Mar 2021 17:38:00 GMT

Use case models include actors and use cases. An effective model must identify both comprehensively. Yet, analysts usually fail to identify all of the relevant actors.

To solve this problem, I like to recommend an approach that maintains a separate use case diagram and actor diagram. Then, the actors from the actor diagram can incrementally be added to the use case diagram as the use case diagram evolves.

What is a Stakeholder Story and how does it compare to a User Story?

Chris Adams — Sun, 12 Apr 2020 19:59:00 GMT

A User Story is perhaps the most widely used Agile technique. It is used to capture product and system requirements from the perspective of the user. Is it the fundamental building block of the Product Backlog. A stakeholder story expands the scope of requirements to non-users of the system.

What are Scenarios within the context of User-Centered Design?

Chris Adams — Mon, 15 Jan 2018 02:20:00 GMT

User-Centered Design (UCD) is an application design methodology which focuses on usability goals, user demographics, real-world environment, tasks, and workflow in the design of an application interface. During the analysis phase of UCD, two key stages are the User Analysis stage and the Workflow Analysis stage.

Describe the life cycle of a User Story?

Chris Adams — Mon, 09 Oct 2017 15:20:00 GMT

User Stories are used by agile methodologies to capture the functionality that a system or software should support. For details about what a user story is and how to write one reference What are User Stories.

How can the acronym INVEST assist the analyst during the development of user stories?

Chris Adams — Sun, 12 Feb 2017 11:56:00 GMT

INVEST is an acronym that can help a Product Manager or Developer create quality user stories. INVEST stands for Independent, Negotiable, Valuable, Estimable, Sized-Appropriately, Testable.

I - Independent: The user story should be self-contained if at all possible to avoid dependencies on other user stories. Since one characteristic of agile methodologies is the ability to be flexible and re-prioritize what’s important, independent user stories allow for flexibility during iteration planning. If you do find that your user stories are dependent upon one another, you may be able to combine smaller user stories together that have a dependency between one another. Similarly, you can divide larger dependent user stories into smaller stories such that one of the new smaller stories contains and isolates the overlapping portion of the larger stories.

N - Negotiable: User stories can always be changed or rewritten up until the point of coding. This further supports the flexibility associated with agile methodologies. Since requirements often evolve or rise and fall in priority, user stories should be able to adapt with the changing requirements.

V - Valuable: A user story represents a goal of an end user or purchaser and should deliver functionality that is deemed valuable. This means that specifics of the technical design are not something that you would document as user stories. However, some technical requirements have a component which is valuable to a user. A user might expect pages to load within 2 seconds. The user story would specify the need for 2 second page load times while the specifics of the physical implementation of this would be left out.

E - Estimable: You should always be able to estimate the size of a user story. Sometimes, developers won’t have the experience required to size a particular situation or needed for a user story. When this occurs the user story can be split into two separate user stories. The first is a “spike” which is where developers do some quick research to determine the feasibility of something or get a better idea of how long it might take to implement the particular feature. The spike is always time-boxed, meaning it is limited to a pre-defined amount of time. The “spike” user story might be named “Research (something) to determine…)”, while the second user story is where the functionality will actually be delivered. These two user stories should be scheduled into two separate iterations such than the spike can be completed and the feasibility of the second user story assessed before coding begins. This gives the team time to react if problems arise from the spike.

S - Sized Appropriately: User stories shouldn’t be too big or too small. So how do you decide what size is right. First, any user story that can’t be completed by a developer within a single iteration (or by a developer pair when paired programming is being used) is too big. The user story should be subdivided into two or more smaller stories. Similarly, there is no need to make user stories too granular just for the sake of decomposing features. If features group well together and complement each other then it makes sense to make a single user story. For instance, “As a job seeker I want to be able to add, delete, and edit a job skill on my electronic resume so that I can maintain an accurate listing of my skills.” There is no reason to split “add, delete, and edit” into multiple user stories unless one of them creates a significant amount of work that would make the user story too large for the iteration.

T - Testable: User stories must be testable in order to ensure that development is complete and has been done correctly. So when are user stories not-testable? Often, if the analyst isn’t carful, non-functionality requirements are written in a manner which is un-testable. Consider the example, “pages should always load quickly”. There are two un-testable components of this statement; “always” and “quickly”. A testable statement would be “pages should load within 1.5 seconds 97% of the time”.

--
Chris Adams
LinkedIn Profile

What is a Mis-Use Case?

Chris Adams — Sun, 08 Jan 2017 20:57:00 GMT

A Mis-use Case, which is derived from Use Case, is a requirements and process modeling term used to describe the steps and scenarios which a user performs in order to accomplish a malicious act against a system or business process. They are still use cases in the sense that they define the steps that a user performs to achieve a goal, even if the goal isn’t a positive one or a desired one from the perspective of the business process or system designers.

What are the essential components of a use case?

Chris Adams — Sun, 09 Oct 2016 18:57:00 GMT

Use case name
Actors
Assumptions/Pre-conditions
Post-conditions
Business rules
Normal process flow
Alternate process flows

What are the basic types of actors that can exist in a Use Case Diagram?

Chris Adams — Sun, 09 Oct 2016 17:00:00 GMT

Actors can be primary or secondary actors. Primary actors initiate a use case, while secondary actors support a use case or receive something of value from the use case.

How do you avoid requirement conflicts while making changes to an existing system where no documentation exists?

Chris Adams — Sun, 13 Dec 2015 20:41:00 GMT

Companies with small IT departments or analysis teams often lack a well defined analysis process. It's not uncommon for analysts to be hired onto a team and find that they are being asked to assist with requirements and new features for a system where no documentation exists. In this case, the analyst needs to create a minimal amount of documentation retroactively.

What are User Stories?

Chris Adams — Sun, 13 Dec 2015 16:00:00 GMT

Extreme Programming (XP), one of many Agile methods, introduced the practice of User Stories to describe what a system or piece of software should do. User stories have since been adopted by many of the agile methods used today.

User Stories are short descriptions of functionality that will be valuable to a user or purchaser of the software or application. They describe the users’ goals when using the system. The initial descriptions can be written by the users, customers, product managers, or developers, and are just a few sentences at most (1-3 sentences being typical). This isn’t the entire user story, but it is all that is created at first.

The development of user stories occurs in three parts; the Card, the Conversation, and the Confirmation.

The Card: Named for the standard index cards on which a user story is often captured, Cards include the brief description of the user story, its relative size to other user stories (called story points), and the priority of the functionality. The cards are used for planning the work that will be completed during each iteration of development. If the size of the user story gets too big to complete within a single iteration then it should be broken into smaller stories. The term used to describe a user story which needs to be further broken down into smaller stories is an “Epic”.
The Conversation: While the conversation itself is not an actual deliverable, it is a critical step in the user story development process. Discussions about each user story are had with the users/customers of the system to flesh out details. The details of the conversations are documented in the form of acceptance tests called “The Confirmation”.
The Confirmation: Acceptance tests are details which are captured from the Conversation that can be used to verify that the user story has been successfully implemented. When index cards are used, the acceptance tests are typically written on the back of the card itself. Acceptance tests can and should be captured whenever they are thought of, however, at the beginning of each iteration there is a defined period of time which is set aside to generate acceptance tests.

Using these three parts, the goal of the user story is to plan which functionality will be developed during each iteration, provide enough detail that a developer pretty much understands what needs to be coded, and provide a means to verify that they have achieved the goal. If the developer needs more details, more conversations are had, the details of which are documented as more acceptance tests.

Here are some sample user stories (the Card) for a job board:

I want to post a resume
I want to search for a job
I want to electronically submit my resume for jobs I like

Some user stories follow a more formal structure than others. One formal approach suggested by Mike Cohn follows the structure: “As a (role) I want (something) so that (benefit)”. At first, structuring your user story descriptions like this may seem like overkill sometimes, but it makes sure that you aren’t forgetting WHO you are designing the functionality for and WHY.

As a job seeker I want to post my resume so that recruiters and employers can find it.
As a job seeker I want to search for a job so that I’m in control of my job search.
As a job seeker I want to electronically submit my resume for jobs I like so that I increase the changes of receiving an interview.

Here are some acceptance tests for the user story, “I want to search for a job”

Test with keyword, salary, and location search parameters
Test that the search results are returned in 2 seconds or less

Some comparisons can be made between user stories and use cases, but there are key differences that should be remembered.

Size and Scope	User Stories have limited scope to fit within an iteration.	Use Cases are almost always larger in scope than user stories.
Structure	User Stories typically represent a single scenario or path through a use case. This could be the main scenario, or an alternative or extension path. Remember that the user story includes the acceptance tests which often describe the details covered in alternative and extension flows.	Use Cases represent a series of related user scenarios. While a main scenario (often the most common scenario) is selected, there are many decision points throughout the flow that branch into alternative or exception flows.
Purpose	User Stories are created to facilitate conversation between the client and development team when the time is right, and have the primary purpose of supporting release and iteration planning process. They are never referred back to as a contract between teams.	Use Cases are written to be understood by both the client and the technology team. They represent a written contract of the desired functionality.
Completeness	User Stories are intentionally written at a goal level initially with just enough detail to describe the user story with just a few sentences at most. Only once the iteration planning begins and more detail will be required the team has conversations to capture acceptance tests.	Use Cases are completed in their entirety early in the analysis and design process. Because of this there exists a natural urge by the customers to place screen specific elements in the use cases themselves, even though there is usually a very strong push by the technology team to try and avoid this. Inevitably the technology team rarely succeeds in keeping UI features out of the use cases.
Longevity	Typically User Stories are not intended to live beyond the iteration in which they are developed. Once the functionality has been developed they are discarded.	Use Cases are often saved and become permanent artifacts representing a permanent contract between the customer and development team.

--
Chris Adams
LinkedIn Profile

What is a Use Case Realization?

Chris Adams — Sat, 08 Aug 2015 16:31:00 GMT

A use case realization provides a construct to organize artifacts which shown how the physical design of a system supports the logical business behavior outlined by a used case. Each use case realization will define the physical design in terms of classes and collaborating objects which support the use case. Therefore, each use case realization typically is made up of a class diagram and a number of interaction diagrams, most commonly sequence diagrams, showing the collaboration or interaction between physical objects.

What is RML (Requirements Modeling Language)?

Chris Adams — Sun, 10 May 2015 23:02:00 GMT

Requirements Modeling language is a collection of diagrams used to model software from the business analysis or product management perspective.

What is the difference between a business use case and a system use case?

Chris Adams — Sun, 09 Nov 2014 17:00:00 GMT

A business use case describes a customer, business worker, or other interested party and how they interact with the business in order to achieve an expected outcome.

A system use case describes how an actor (customer, business worker, or even another system) interacts with a specific system.

What is the difference between a use case alternative flow and an exception flow?

cadams — Sun, 12 Oct 2014 06:13:00 GMT

A use case specification describes the functionality of a system in terms of a sequence of user-system interactions. The main flow of events describes a single path through the system. It represents the most common way that the use case plays out successfully and contains the most common sequence of user-system interactions. Other scenarios or paths through the system are described in alternative flows and exception flows. So what is the difference between and alternative flow and an exception flow?

Can requirements for a system interface be documented as a use case?

Chris Adams — Wed, 04 Dec 2013 22:08:00 GMT

Yes, a use case can be used to document requirements for system-to-system interactions and exchanges of information between systems. External systems are treated as Actors, in the same way as human Actors. The standard use case structure of pre-conditions, post-conditions, basic flow, alternate flows and exception flows are all applicable when describing the requirements for interactions with an external system Actor as with a human Actor.

A key rule for this type of use case is that external systems must always be treated as ‘black-box’ entities. The use case cannot dictate requirements for external system processing beyond the bounds of its interaction with the in-scope software system. For example, requirements for an online retail sales system (“System X”) may include an interface to an external third-party payment system such as Paypal (“System Y”). The use case for this interface would describe what information shall be sent from System X to the external system Actor, what information shall be received by System X from the external system Actor, and what System X shall do in order to process the information exchanged. The use case cannot contain requirements for any processing that occurs within the external system (cannot describe data that System Y must collect, connect describe edits that System Y should perform, etc.).

Pre-conditions also must not describe anything that happens within the external system. A pre-condition can only be something that is known to or detected by the in-scope system.

--
Sandy Lambert
Business Architect
LinkedIn Profile

When do you use the Use Case relationship Extend versus Include?

Chris Adams — Mon, 12 Nov 2012 01:22:00 GMT

The UML Use Case relationships Include and Extend remain a point of confusion for many business analysts.

Both the include relationship and the extend relationship build off of a base use case. In theory, a business analyst could write a base use case and never use the include or extend relationships. However, as use cases become larger and more complex with numerous alternate flows choosing to use include or extend can reduce the complexity of the base use case and improve the overall understandability of the use case model.

So when would a business analyst choose to include another use case?

The most predominant reason to create an included use case is for reuse. The include relationship can be used to segment out a series of contiguous steps which can then be reused by other use case. The including use case can often be a standalone use case of its own which is initiated directly by an actor, but it doesn’t have to be. However, it is a required step in the use can which includes it, and it is included at a single specific location in the base use case. This means that the base use case isn’t complete without its included use cases. Additional, based on the direction of the association arrow, you can see that the base use case has knowledge of the existence of the included use case. However, the included use case doesn’t know about the use cases that include it.

When would a business analyst use and extends relationship?

The extend relationship is used to segment out conditional or optional functionality, and is comparable to an alternate flow. Often while writing use cases alternate flows can become quite complex, or can span additional subflows. This is when it may make sense to extract the alternate flow as a separate use case which extends the base use case. This is called an extension use case. Of course this is only advantageous if the flow to be extracted is reasonable self-contained from the main flow. If the two are too intermingled then the extension use case will be difficult to understand.

The extension use case is aware of and can modify the behavior of the base use case. However, the base use case has no knowledge of the extension use case. An extension use case can have one or several behavioral sequences called segments that modify the base use case. Each segment augments the base use case at a specific extension point noted in the base use case. Additionally, the condition under which the the base use case is augmented is defined by the extension use case.

To summarize:

Include Relationship

Use to segment out a reusable series of steps

Base use case is incomplete without the included use case (use include for required behavior)

Include use case isn’t aware of the use cases that use it (this becomes even more important from a system coding perspective)

Extend Relationship

Similar to an alternate flow, it contains optional or conditional behavior

An extension use case is incomplete without the base use case

Extension use cases are often used for behavior that will be implemented at a later time

If enhancing an existing system, using Extend can help separate new functionality from old

What are Use Case Points?

Chris Adams — Sun, 13 Mar 2011 22:02:00 GMT

Use Case Points are similar to Function Points in many ways as they are used to size and estimate the cost of work on systems. Use Case Points are a normalized unit of measure used to:

Quantify the amount of business functionality a system provides business users

Estimate the cost to develop a system or set of features based on the number of use case points it supports

Determine how costly a system is to maintain based on the number of use case points it supports

The number of Use Case Points is derived from factors such as:

The number of system use cases and the complexity of the use cases

The number of system actors

Non-functional requirements that are not captured as use cases but that have an overall impact on system complexity

The project environment including the architectural framework, programming language, team structure and efficiency, etc

The system’s Use Case Points are calculated as follows.

First, to arrive at an Unadjusted Use Case Weight (UUCW), the analyst counts the number of user and system activity steps that occur in a use case (including its main and all of its alternative flows and extensions). The term activity step is specifically used because this does not include the decision step such as determining if an entry is valid (yes or no). It would, however, consider the system’s response to the invalid entry. The number of activity steps is used to assign a complexity to each use case. The number and complexity of each use case are then combined to determine the system’s Unadjusted Use Case Weight. UUCW = (# of Use Cases) x (Weight based on complexity)

Complexity	#of Activity Steps	Weight
Simple	1-3	5
Average	4-7	10
Complex	8 or more	15

Next, the Unadjusted Actor Weight (UAW) is calculated. Each system actor is counted and assigned a complexity level. A system actor interacting with the system under consideration through a standard API is considered simple. As human actors using GUIs are introduced, or as various data mappings have to occur between an Actor and our system, the complexity increases. Each actor and its complexity is used to arrive at the Unadjusted Actor Weight. UAW = (# of Actors) x (Weight based on complexity)

Actor Type	Example	Weight
Simple	Another system via an API	1
Average	A person via a text-based interface	2
Complex	A person via a GUI	3

Adding the UUCW and UAW together gives you the Unadjusted Use Case Points (UUCP).

The results of Use Case Points are typically more consistent when use cases are written at a similar level of granularity across the system.

Next, the Use Case Points method accounts for Technical and Environmental Factors. There are 13 standard Technical Complexity Factors (TCF) that are considered and each has a predefined weight. They are:

Technical Complexity Factors	Weight
Distributed system	2
Performance objectives	2
End-user efficiency	1
Complex processing	1
Reusable code	1
Easy to install	.5
Easy to use	.5
Portable	2
Easy to change	1
Concurrent use	1
Security	1
Access for third parties	1
Training Needs	1

Similarly, there are 8 Environmental Factors (EF) that are consider, each with its own weight.

Environmental Factors	Weight
Familiar with the development process	1.5
Application experience	.5
Object-oriented experience	1
Lead analyst capability	.5
Motivation	1
Stable requirements	2
Part-time staff	-1
Difficult programming language	-1

For each of the Technical and Environmental Factors a value between 0 and 5 is assigned to represent the degree of influence the factor has on the particular project and system being designed. Some will have no influence (0) while others will have a very large influence (5). For example, if it’s a highly distributed system, the influence for the TCF #1 might be a 5, resulting in a value of 10 (TCF Weight x Influence).

By multiplying each factors weight value by its influence value and summing them all together the TF and EF can be determined.

Finally the Adjusted Use Case Points (UCP) is calculated using the formula: UCP = UUCW x TCF x EF.

What is the difference between a Primary and Secondary Actor in Use Case Modeling?

Chris Adams — Sat, 09 May 2009 22:10:00 GMT

What are some of the limitations of use cases and use case specifications?

Vineet Banwet — Fri, 06 Feb 2009 05:00:00 GMT

Use cases are a valuable tool available to the business analyst for documenting functional requirements of a system or business, however they do have limitations.

Use cases were not created to capture non-functional requirements (e.g performance, platform, scalability, reliability of a system). While use case specification templates have been extended by some in an ad-hoc fashion to list non-functional requirements, this strays from the intended purpose of a use case. Use cases are functional in nature. It is this very organization by function that give use cases their many benefits. Arbitrarily listing non-functional requirements in one use case specification or another can obfuscate the cohesiveness and benefits of the use case specification.
The non-sequential nature of a use case diagram is often difficult for some audiences to understand. When one use case includes or extends another, the reader of the diagram often arrives at the incorrect conclusion that the use case diagram is showing a sequence where the first use case is completed before the other begins. Those who are familiar with use case diagrams know that an included or extended use case can occur or be initiated at any point within the including or extending use case.
Learning how to write use cases takes time. Many consider it to be more of an art than a science. This is because there is no fully defined set of standards for how to write use cases, or what should be included within a use cases specification. And while there have been many different views espoused by authors, still a great deal of commonality has emerged among them. Where this commonality exists there is little disagreement among use case writers and those who consume or read use cases. However, in some areas there are still a number of differing opinions creating confusion for new use case authors. Because of this, the learning curve for use cases and use cases specifications is elongated. Still, over time, use case authors and readers develop a more sophisticated understanding of those areas that are more ambiguous and open for interpretation, such as the “extends” relationship.
Use case specifications are not an appropriate tool for describing the user interface of the application. Use cases should be left as UI independent as possible. Remember that a use case specification it intended to capture the functional requirements of the system, or in other words, WHAT the system should do in response to a user action. This is very different than HOW the system should do something. Any time an analyst captures requirements, the focus should be on the WHAT not the HOW. This gives the system and UI designer the freedom to develop the best solution possible. It also makes our use case specifications much more maintainable since a change in screen design doesn’t impact the user-system interaction previously defined.

What is the difference between a use case specification and a use case realization ?

Vineet Banwet — Tue, 06 Jan 2009 16:16:00 GMT

A Use Case Specification is a textual description of the functionality provided by the system. It captures actor-system interaction. That is, it specifies how a user interacts with a system and how the system responds to the user actions. It is often phrased in the form of a dialog between the actor and the system. The use case specification is represented in the use case diagram by an oval, and is what most people think of when they hear the term use case.

A Use Case Realization describes how a use case, which is logically defined by the use case specification, is physically implemented within a design model in terms of collaborating objects. It organizes the design model artifacts related to the use case. It often comprises multiple design artifacts such as a class diagram, object diagram, sequence diagram, etc. that describe how the physical design will implement the use case specification.

The purpose of use case realization is to separate the concerns of the system stakeholders, which are typically captured by the use case model and system requirements, from the concerns of the system designers. In doing so, the designers can choose to implement the use case specification without affecting the use case specification.

Which project participants benefit from Use Cases?

Chris Adams — Wed, 01 Oct 2008 20:20:00 GMT

The full benefit of use cases are not always understood by all. Use cases provide more benefit than simply capturing functional requirements of the system, and therefore benefit more project participants than just the commonly understood project stakeholders. Here are some of the beneficiaries of use cases.

Project Stakeholders: For project stakeholders, use case models and use cases specify the functionality and interaction that a user will have with the system. It is written in a simple to understand form so that it can be understood by even the most diagram adverse individuals. By reviewing and gaining signoff from the project stakeholders, use cases help analysts validate that the system will meet the functional requirements expected by the stakeholders and will as a contract of what will be delivered.

Developers: Use case models provide a high level overview of the system functionality to the developers. The use cases and use case scenarios add the detail required for a clear understanding of system functionality and provide a solid foundation for the developers to continue with detailed design. By completing the detailed design with the use case model as a guide, the system design remains user-centric ensuring that the final system delivers on the requirements and needs of the stakeholders.

Analysis, Development, and QA Managers: Use case models are an excellent tool for estimating the level of effort required to complete analysis, development, and testing of the application. The use case model divides the system into logical pieces that can be assigned a complexity value and then each use case can be estimated and aggregated to create a final effort estimation.

Project Managers: Use case models are a great tool for project mangers to plan and track the progress of work. Use case models become especially useful in iterative development environments where iterations are planned around the successful implementation of use cases. Use cases are often used in this way because it is easy for stakeholders to see the value of each use case, and therefore the value of each iteration of the application that has been implemented.

Integration and System Testers: Use cases and use case scenarios directly translate into test cases and test scenarios that are used to validate and verify the successful implementation of the system requirements.

Anyone Requiring System Knowledge: Any time someone needs to know what a system does, one of the best places to start is the use case model. By reviewing the use case model, anyone can gain a quick understanding of the functionality of the system. Once they find the use cases that reflect the functionality that pertains to them, they can then look at the details of each use case and gain an immediate understanding of the functionality supported.

How do you identify your list of use case actors?

Chris Adams — Wed, 01 Oct 2008 18:45:00 GMT

An actor is someone or something that interacts with the system by sending or receiving messages or information to and from the system. Primary actors initiate the interaction with the system. Secondary actors do not initiate the interaction with the system but participate in one or more use cases of the system, often providing information back to the system.

Use case actors can be identified by asking a number of questions:

Who will use the system to perform their normal daily work?

Who will maintain, administer, or configure the system?

Who will use the output, information, or reports from the system?

What systems or services will require information from the system?

What systems or services will provide information to the system?

What other applications need to interact with the system?

Your turn: What method do you use to identify the actors in your use case diagram?

What is use case generalization?

everest — Tue, 27 May 2008 18:10:00 GMT

In the context of use case modeling the use case generalization refers to the relationship which can exist between two use cases and which shows that one use case (child) inherits the structure, behavior, and relationships of another actor (parent). The child use case is also referred to the more specialized use case while the parent is also referred to as the more abstract use case of the relationship.

For those of you familiar with object oriented concepts: use cases in UML are classes and the generalization is simply the inheritance relationship between two use cases by which one use case inherits all the properties and relationships of another use case.

You can use the generalization relationship when you find two or more use cases which have common behavior/logic. In this instance, you can describe the common parts in a separate use case (the parent) which then is specialized into two or more specialized child use cases.

Example:

If you are creating a payment system which allows students of a training provider to pay for courses both on-line and by phone, there will many things in common between the two scenarios: specifying personal info, specifying payment info, etc. However, there would also be differences between the two. So, the best way to accomplish this is to create one use case (the parent) which contains the common behavior and then create two specialized child use cases which inherit from the parent and which contain the differences specific to registering on-line vs. by phone.

What is actor generalization?

everest — Tue, 27 May 2008 17:18:00 GMT

In the context of use case modeling the actor generalization refers to the relationship which can exist between two actors in a use case diagram and which shows that one actor (descendant) inherits the role and properties of another actor (ancestor). The generalization relationship also implies that the descendant actor can use all the use cases that have been defined for its ancestor.

For those of you familiar with object oriented concepts: actors in UML are classes and the generalization is simply the inheritance relationship between two actors by which one actor inherits all the properties and relationships of another actor.

Example 1:

When it comes to air travel, both a "Business Traveler" and a "Tourist" are "Passengers". The fact that they are passengers allow them to have common behavior such as "Buy Ticket" but the fact that they are separate actors implies they can also have differences. The "Business Traveler" might be able to "Redeem Business Miles" while the "Tourist" cannot.

Example 2:

Another scenario often found in many systems is when the system administrator, who gets additional functionality, is actually one of the normal users. So let's say that the system is an accounting system with the main actor being "Accountant" and with another actor called "Administrator". In our scenarios the Administrator should be able to perform all the normal accounting functions in addition to his/her administrator role.

The way to model this would be to show relationships between the Administrator actor and all the admin only use cases, then show all the accounting specific use cases related to the "Accountant" actor. And now, the only other thing you need to do for the "Administrator" to have access to the accounting features is to use the generalization relationship between the "Accountant" and the "Administrator" with the Administrator actor (descendant) inheriting from the Accountant actor (the ancestor).

Are use cases the functional requirements or do you think functional requirements are different from use cases?

everest — Fri, 02 May 2008 03:29:00 GMT

It is generally accepted that use cases, specified in narrative form (also known as use case specifications), depict functional requirements. This is because a use case, via the main and alternate flows, shows how a user interacts with a system in order to achieve a desired result.

That's exactly the purpose of a "functional requirement" to describe the functions and behaviors that a system is or should be capable of.

Therefore, if use cases are used and narrated in detail for a project, there is no need for separate documentation to describe the functional requirements because the totality of all the use cases represent the set of functional requirements for a given system/project.

What type of information should be documented in a use case specification?

MostafaElbarbary — Fri, 18 Apr 2008 19:30:00 GMT

While use cases are included in the Object Management Group’s UML® Specification, the UML specification does not define the form or content that should be included in a use case specification. For this reason, there is no single standard. Precisely what information should be included varies based the source you reference. Nevertheless, most methodologies and authors show a significant degree of agreement regarding the information that should be included in a use case specification.

The most popular use case specification template is probably the Rational Unified Process Template. It includes the following information.

Use Case Name
Brief Description
Actors
Triggers
Flow of Events
- Basic Flow
- Alternative Flows
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points

In his book, Writing Effective Use Cases, Alistair Cockburn (2001) shows several examples of use case specifications, most of which include the following information:

Context of Use
Scope
Level
Primary Actor
Stakerholders and Interests
Preconditions
Minimal Guarantees
Success Guarantees
Trigger
Main Success Scenario
Extensions
Technology and Data Variations list
Special Requirements

Additionally, Scott Ambler (2004) offers a simplified template in The Object Primer that includes the following information:

Name
Identifier
Description
Goal
Pre-conditions
Post-conditions
Basic course of action
Alternative course of action

References:

Cockburn, Alistair. 2001. Writing Effective Use Cases. Addison-Wesley Professional.

Ambler, Scott W. 2004 The Object Primer: Agile Model-Driven Development with UML 2.0 (Third Edition). Cambridge University Press.

What is difference between an Essential Use Case and a System Use case?

MostafaElbarbary — Fri, 18 Apr 2008 19:21:00 GMT

“An essential use case is a structured narrative, expressed in

the language of the application domain and of users,

comprising a simplified, generalized, abstract, technology-free

and implementation independent description of one

task or interaction that is complete, meaningful, and well-defined

from the point of view of users in some role or roles

in relation to a system and that embodies the purpose or

intentions underlying the interaction” (Constantine and Lockwood (1999).

Said another way, an essential use case describes the interaction between the user and the system at a high level of abstraction. The goal of an essential use case is to convey the most important aspects of the user-system interaction by focusing on the user’s intent (avoiding any reference to an assumed UI design or technological implementation) and on the observable result of the system (without specifying the internal steps the system takes to achieve the result). Since an essential use case describes only the most important information it represents a single success scenario.

In contrast, a system use case describes the interaction between the user and system in a more detailed way than and essential use case. While still trying to avoid referencing any UI specific features when possible, usually certain aspects of the technology to be used can be assumed. For instance, when writing a system use case, it is usually known whether the user will interact with a telephonic system, an internet application, or a piece of manufacturing equipment. Similarly, system use cases provide more detailed description of the steps that the system will perform to fulfill the need of the user. In order to avoid committing to a specific UI design, this detail should still be expressed in logical terms. However, it paints a clearer picture of the requirements that the GUI must satisfy.

References:

Constantine, Larry L., and Lucy A. D. Lockwood. 1999. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Addison-Wesley Professional.

What are some of the formats used for writing use cases?

MostafaElbarbary — Fri, 18 Apr 2008 19:06:00 GMT

To ensure that we understand what is meant by the term format, consider the following. Most authors and practitioners do not clearly differentiate between style and level of detail when defining use case writing formats. Style refers to the structure of the use case or how the use case information is presented. Level of detail refers to the state that a use case is in as it evolves from nothing more than a use case name to a fully described or fully dressed use case. Most authors and practitioners generically use the term format to describe some combination of these two concepts.

What is a use case description (specification)?

Chris Adams — Mon, 24 Sep 2007 23:28:00 GMT

A use case description (also known as use case specification) is the textual documentation of an interaction with a business process or IT system in order to achieve something of value (a goal). There are two common formats used for creating use case descriptions. One is the narrative form which describes the interaction in paragraphs, much like telling a story. The other is the dialogue or conversational form, which describes the interaction just as two people might have dialogue, i.e., the actor does A, then the system does B in response.

While it may vary by organization, a use case description typically contains the following:

- Use Case Name

- Brief Description

- Pre-Conditions

- Main Flow of Events

- Alternative Flows

- Exception Flows

- Post Conditions

What is a use case?

Chris Adams — Mon, 24 Sep 2007 23:18:00 GMT

A use case is a representation of an interaction between business worker and a business process or a user and an IT system in order to achieve something of value (a goal). Use cases are the ovals that appear in a use case diagram. A use case and a use case description or specification are different. While use cases represent an interaction (usually with a simple verb-noun phrase) use case descriptions/specifications describe the interaction in detail form.

Use cases can be subdivided into business use cases and system use cases. Business use cases represent the interaction between a business actor and a business process in order to achieve a goal, while system use cases represent the interaction between a system actor, which can be a system user or another system, and an IT system in order to achieve something of value.